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METHOD AND APPARATUS FOR A NETWORK HUB TO DIAGNOSE 
NETWORK OPERATION AND BROADCAST INFORMATION 
5 TO A REMOTE HOST OR MONITORING DEVICE 

CROSS-REFERENCE TO RELATED APPLICATION 

The present application claims the benefit of the filing 
date of United States Provisional Patent Application Serial No. 
10 60/136,083, filed May 26, 1999, and entitled METHOD AND APPARATUS 
FOR A NETWORK HUB TO DIAGNOSE NETWORK OPERATION AND BROADCAST 
INFORMATION TO A REMOTE HOST OR MONITORING DEVICE, the contents 
of which are hereby expressly incorporated herein by reference. 

15 BACKGROUND OF THE INVENTION 

Modern data communication networks are generally star-wired 
"hub and spoke" topologies, with a centralized hub, and multiple 
spokes which attach to each end-station, generally a computer or 
computer peripheral device. The centralized hub typically is 

20 responsible for conductivity between the individual devices and 
the network, and may provide a wide range of additional 
functionality. For instance, a simple Ethernet repeater is 
responsible for signal timing and amplitude restoration, 
basically receiving data from one port and repeating it to all 

25 other ports. Data received from two or more ports simultaneously 
constitutes a collision, causing the repeater to issue a "jam" 
sequence to all ports. The transmitting end-stations will detect 
the collision condition and back-off, and reschedule their 
transmission attempt after a predetermined interval. Repeaters 

30 usually operate at the physical layer (Layer 1) of the OSI 
7-layer model. 

A network switch has added functionality, which may allow 
multiple simultaneously conversations to exist between its ports. 
Generally, the switch stores a packet (or a portion of it) for 
35 some period of time, while it inspects the contents of the 
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packet, and makes a determination as to which port(s) the packet 
should be forwarded. The switch forwards packets only to where 

5 they are destined. It does not forward frames to all ports, as 
in the case of a repeater, except in the case where it cannot 
resolve the frame contents to determine which port(s) should 
receive the frame. Switches may operate at Layer 2 (MAC layer), 
in which case they are called bridges, or Layer 3 (the network 

10 layer) in which case the switches can be referred to as routers. 
Bridges and routers initially were software-based, requiring a 
processor to make the forwarding decision. Network switches are 
generally hardware-based. Advances in VLSI technology have made 
it possible to integrate the functionality of a bridge (Layer 2 

15 switch) or router (Layer 3 switch) into silicon. 

A result of these integration capabilities has been the 
dramatic cost reduction of hub, or network infrastructure 
products. This has occurred to such an extent that star-wire 
topologies have been able to displace the older, traditional 

20 bus-based topologies, such as the original coaxial cable-based 
Ethernet and Cheapernet, with 10BASE-T and 100BASE-T repeater- 
based technologies. This initially occurred in the corporate 
environment, where the additional advantages of the star-wire 
topologies were of substantial value. For instance, fault 

25 isolation and diagnosis can be easier in a point-to-point 
environment where an individual station can be isolated from the 
rest of the network. Additionally, the centralized hub function 
can be a natural place to implement network management, since 
traffic can be monitored at each port, and statistics gathered 

30 to determine the performance of the network. However, simple 
networks, such as for small offices or even in homes, do not 
require sophisticated management, because it generally adds 
significant overall cost to the system and is not very useful 
because in these environments, a professional network manager is 

35 not present. 
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SUMMARY OF THE INVENTION 

The invention herein provides a network hub in a 

5 communication network that acts as a server to network clients 
to push, or transmit, information regarding the state of local 
and remote devices and networks. The information can be one, or 
more, status information, which information can be one or more 
predefined fields in a frame, which represents a packet of data. 

10 In one embodiment, it is desirable that the frame be a 
"legitimate" Ethernet-type frame. The status field can be a 
"push"-Type status field. The push operation can be a unicast, 
a multicast, or a broadcast, or a hybrid transmission. The hub 
can be a switch, repeater, a bridge, a router, a gateway, or a 

15 hybrid thereof. Also, the hub according to the present invention 
can be an OSI Layer 2 device, an OSI Layer 3 device, or a hybrid 
thereof. It is desirable that the hub be devoid of a 
microprocessor. As described herein, the hub may have plural 
ports, for example, four, eight, or more ports. 

20 The hub according to the present invention includes memory 

registers, for example, for storing information such as 
management information base (MIB) statistics. The hub also can 
have a MIB engine. It is preferred that the hub integrally 
include a transceiver (PHY) and switching fabric, and, 

25 additionally, an address resolution table. 

In another embodiment, the communication apparatus of the 
present invention can include a network detector detecting 
information representative of the state of a local or remote 
device or network, a network information table storing the 

30 information, and a network information transmitter for push 
transmitting the information to a number of clients. Optionally, 
a network analyzer may be included into the hub. The network 
analyzer can produce information of the state of the network by 
analyzing information in the network information table, such as 

35 a MIB, and provide the information to the network information 
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transmitter which, in turn, can push transmit the information to 
selected clients coupled to the communication network. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagrammatic representation of an embodiment of 
the present invention; 

FIG. 2 is a block diagram illustrating a communication 
10 apparatus according to the invention herein; 

FIG. 3 is a diagrammatic representation of a MIB Autocast 
packet of the present invention; 

FIG. 4 is a block diagram of a network hub according to the 
present invention, containing an integrated network switch, 
15 similar to FIG. 2; 

FIG. 5 is a block diagram of a high-port-density network hub 
according to the present invention, containing plural integrated 
network switches, similar to FIG. 2; 

FIG. 6 is a block diagram of another embodiment of the 
20 invention herein; and 

FIG. 7 is a block diagram of yet another embodiment of the 
present invention . 

DETAILED DESCRIPTION OF THE INVENTION 

25 Network management in a small office/home office (SOHO) 

environment has not been provided, primarily due to cost. Such 
management typically employs memory and components to monitor and 
collect the network statistics, as well as a separate processor 
to either display this data directly, or to pass it to a remote 

30 network management entity. Current high performance desktop 
computing and web-based programming tools such as HTML and Java™ 
make possible an intuitive, easy-to-operate, graphical user 
interface (GUI) which an unsophisticated user can operate using 
a series of display menus. 

35 
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The current model for network management is "pull" 
technology, by which a client device requests a server device to 

5 send specified data. in a networked environment, data can be 
gathered by various devices in a network and stored in a 
predetermined network information memory, such as, for example, 
a Management Information Base (MIB) . An MIB, as used herein, can 
be a table that contains relevant network statistics and data, 

10 and can be defined by IEEE standard 802.3, clause 30, although 
one skilled in the art would realize that other network 
management schemes may be used. Numerous standardized MIBs exist 
for particular classes of equipment, so that equipment from 
different vendors can interoperate . A centralized network manager 

15 polls these MIBs at some predefined interval to collect data. 
Data also is collected if an alarm state is generated by one of 
the network devices. Standard protocols are used to gather this 
information, the most common standard protocol being the Simple 
Network Management Protocol (SNMP) . Data can be gathered, 

20 processed, stored, and/or displayed at this central location. 

Embodiments of the invention herein employ "push" technology 
for network information management. In general, push technology 
is one by which a server, or data source, transmits information 
to a client, or data recipient, without a specific request for 

25 that information from the client. Push technology can employ 
unicasting, multicasting, broadcasting, or a hybrid thereof. 
Push technology network devices may be used in both a SOHO 
environment, as well as in a more sophisticated enterprise, or 
global, network environment. 

30 FIG. 1 illustrates an embodiment of the present invention. 

Network hub 100 transmits status information 102 regarding 
network 104 to attached network devices, or stations, 106, 108, 
110, 112, 114, typically in a periodic manner. Hub 100 can be a 
a switch, a repeater, a bridge, a router, a gateway, or a hybrid 

35 thereof. These transmissions can be limited either by 
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transmitting only on specific ports 120, 122, 124, 126 of hub 
100, or by having only the appropriate receiving device (s) 106, 
108, 110, 112, 114 programmed to accept packets sent to a 
specific network address , while all other stations drop these 
packets. The status information 102, preferably in the form of 
data frames, are sent sufficiently infrequently so as not to 
cause any significant traffic loading on network 104. 

Because the information is transmitted, it is not necessary 
for a processor to be present in the hub device, in order to 
parse and respond to SNMP GET/SET requests. This can reduce 
complexity in costs in network hub 100, and can move feature 
differentiation, from a network management perspective, into the 
specialty software domain. 

By supporting a very simple set of commands, this transmit 
reporting function can be turned on or off, such that an external 
management entity, e.g., station 110, can gain access to the 
information only when needed. Use of simple commands to hub 100, 
as passed over network 104, can increase the granularity of the 
data presented, so that more detailed information can be obtained 
by the external agent which then may be presented to experienced 
personnel for in-depth analysis of the information. 
Alternatively, graphical user interface 130 can be used to assist 
this process. 

In a typical small network installation, similar to network 
104, only one network device, for example device 110, will 
capture/process the transmitted status information frames 102. 
A network application loaded onto device 110 (typically a PC) can 
process the data and present graphical user interface (GUI) 103 
that is appropriate for the end user application. For instance, 
an application may provide two different classes of menus or 
screen options. The first may be for the unsophisticated user, 
where the management software actually performs substantial 
processing and/or analyzing of the received status information, 
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such as in an expert system. It then can make simple 
recommendations to the user, in order to diagnose the status of 
5 the network, or of a potential problem. A second set of screens 
simply may present the collected statistical data in a raw, 
tabular format, for analysis by a trained network troubleshooter . 
Access to these menus may be restricted to authorized technical 
personnel . 

10 FIG . 2 shows a simple block diagram of a switch device 200 

which is an embodiment of the present invention. Using a n MIB- 
Autocast" feature, integrated network switching circuit 200 
periodically transmits data field 202 of a preselected format, 
for example, a properly-formatted Ethernet frame, on a designated 

15 switch port or ports. The data fields, or frames, can be 
intercepted, for example, by an external management probe, or a 
dedicated network management application, resident on a node 
within the network. 

Exemplary device 200 is a fully-integrated managed Layer 2 

20 (L2) switch circuit, which can incorporate all of the key 
functions to enable a system product based on the device to be 
targeted at the enterprise switch market, or alternatively, at 
the SOHO connectivity market. One such exemplary device 200 
includes, without limitation, the BCM5308M 9-Port Managed 

25 10/100BASE-T/TX Switch, from Broadcom Corporation, Irvine, CA. 

Device 200 may integrate all of the major switching 
functions onto a single die, including switching fabric 202, 
address resolution logic 204, MIB engine 206, HDLC/SMP Interface 
208, multiple Ethernet MACs 210a-210i, multiple 10/100 Mb/s 

30 Ethernet PHYs 212a-212h, SSRAM interface 214 for external packet 
storage, as well as hardware counters 216 to support multiple 
industry-standard MIBs. Although device 200 is shown with nine 
MACs 210a-210i, and eight PHYs 212a-212h, it will be appreciated 
that a greater (e.g., sixteen), or fewer (e.g., four), number of 

35 MACs and PHYs may be used to implement the present invention. 
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In this example, switch device 200 maintains multiple per- 
port counters 216, e.g., forty counters per port, for the key MIB 
attributes that can increment based on packet activity. These 
counters can be a combination of transmit, receive, and shared 
counters. The MIB Autocast feature allows the statistics to be 
packed into a normal Ethernet frame that switch device 200 
constructs at regular time intervals. Other aspects of the MIB 
data that are generally static in nature, are assumed to be 
maintained in other ways, such as by a processor, by non-volatile 
memory, etc. 

It is desirable that, using MIB Autocast, management 
information be conveyed with minimal impact on the system cost 
of the switch device. MIB Autocast frames can be captured and 
processed, stored, or analyzed as a background activity in any 
of the existing network nodes. It is most desirable that MIB 
Autocast technique be configurable to forward information to any 
port or port group. This can include the ability to cast frames 
only at the local CPU, attached via the management port of 
choice. This technique can be used to off-load routine processor 
reads on MIB registers 216. MIB statistics registers 216 can 
collect, receive, and transmit statistics for each port, and 
provide direct hardware support for the EtherLike MIB, Bridge 
MIB, MIB 2 (interfaces) and selected groups of the RMON MIB. 

A stand-alone implementation of the aforementioned switch 
device 200, which has eight 10/100 Mb/s ports 212a-212h, 214 and 
one Mil port 224, can have nine frames queued to each of its nine 
output ports. The feature of casting to output ports also is 
programmable, and is based on a port mask register within device 
200. This allows each output port to be programmed individually 
as to whether it will have MIB Autocast frame 300 queued to it. 

As an example, switch device 200 actually may have eleven 
physical ports, because, in addition to ports 212a-212h and 224, 
there is expansion port 220 and serial management port (SMP) 218. 
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In this example, expansion port 220 may be used to interconnect 
multiple switch devices 200 to create a higher port density 

5 switch. Similarly, serial management port 218 may be used to 
configure and manage the device. In an embodiment of the present 
invention, the default port mask for MIB Autocast frames can be 
03FFh. This will enable MIB Autocast frames to be transmitted 
over the nine network ports 212a-212h, 224, and expansion port 

10 220 but disables transmission over SMP 218. The port mask may 
be stored in a programmable register, so it may be modified by 
connecting to SMP 218, an external microcontroller, as shown by 
microcontroller 416 in FIG. 4, or a state machine. 

FIG. 3 illustrates a general format of MIB Autocast frame 

15 as implemented by a switch device. Each MIB Autocast frame 300 
has multiple fields 302, 304, 306, 308, 310, 312, 314a-e, 316. 
Among the fields that can be included in frame 300 are 
Destination Address field 302, Source Address field 304, Type 
field 306, OPCODE field 308, Port Number field 310, Port State 

20 field 312, MIB Statistic fields 314a-314e, and FCS field 316. 
Each field can have extensions that permit extended information 
for expanded and scalable switch devices. While one embodiment 
allows a statistic report frame for each port to be individually 
constructed, it may be desirable to report switch performance, 

25 diagnostic, or configuration information, as well. 

The hub (similar to hub 100 in FIG. 1, or switch device 200 
in FIG. 2) can construct frame 300 of the general format shown 
in FIG. 3, preferably on a periodic basis. The period can be 
programmable to allow sufficient frequency of reporting, while 

30 not generating excessive network traffic. At each programmed 
time period, the hub gathers the statistics information for each 
of its ports, and constructs a frame containing this port- 
specific information. These statistics can be representative of, 
for example, an operational state of the network. Although ports 

35 that are disabled are unlikely to have changed status 



-9- 



1 34729/JFO/B600 

information, those statistics may nevertheless be gathered. A 
copy of the frame representative of a respective port then can 

5 be transmitted, or "cast/ 7 to each output port in the switch. 

In one embodiment of the present invention, fields within 
the MIB Autocast frame can be programmable, such as the 
Destination Address 302, Source Address 304, Frame type 306, etc. 
Some fields can be hard coded, such as, for example, OPCODE field 

10 308. In addition, the order and content of the frame with 
respect to the actual fields/MIB counters that are compacted 
together to make frame 300, can be hard coded. OPCODE field 308 
allows simple two-way communication between a host management 
system, and the MIB Autocast function in the hub or switch 

15 device. 

For example, the hub can recognize frames 300 directed to 
its specific MAC addresses and direct these to the management 
entity 110 as indicated in FIG. 1. In this case, referring back 
to FIG. 2, the single MAC address assigned to the switch 200 can 

20 be instantiated in the address resolution logic 204 as a static 
entry, with the egress port 208 identified as the Serial 
Management Port. The management system then can operate on this 
frame 300, determine if it is a M MIB Autocast configuration 
message" depending upon Type field 306 and OPCODE field 308, and 

25 take appropriate action. Such action can include increasing the 
granularity of reports, that is providing more frequent MIB 
Autocast frames 300, or more detailed data within frames 300; 
enable/disable the MIB Autocast function remotely; change the 
port mask; etc. These actions permit a closed-loop management 

30 system to be built where an external management entity monitors 
the MIB Autocast frames, and under specific conditions, it can 
recognize the frequency and/or content of the frames to enable 
a fault, or error condition, to be analyzed in more detail. The 
normal monitoring function can be resumed after the analysis has 

35 been completed. Once the exact configuration modes are defined, 
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it may be desirable to hard code the modes to support a number 
of options. 

Some exemplary assignments to OPCODE field 308 that can be 
used as extensions to the MIB Autocast protocol include, without 
limitation : 

1. Program the default port mask from which MIB 
Autocast frames 300 are transmitted; 

2. Change the destination address 302, source 
address 304 and/or Type fields 306 of the 
transmitted MIB Autocast frame; 

3. Modify the time interval when MIB Autocast frames 
300 are transmitted; 

4. Disable/enable a physical switch port; 

5. Restart autonegotiation on a specific switch 
port; 

6. Enable/disable full duplex or pause capability on 
a specific switch port; 

7 . A supply and program additional header bytes to be 
inserted in MIB Autocast frame 300; and 

8. Specify the internal registers, counters, or 
states that are to be included, or excluded, from 
MIB 300 Autocast frame. 

The MIB Autocast function can be extensible in that it 
allows multiple devices in a network, and multiple chips in each 
device, to issue MIB Autocast frames. Operating multiple MIB 
Autocast devices in the network can be achieved because each MIB 
Autocast-capable device (e.g., device 200 in FIG. 2) can have its 
own unique 48-bit MAC address. Generally, it will be casting 
frame 300 to a well-known address, such as a default, learn, or 
assign unicast or multicast destination address. In a L2 switch 
network, the MIB Autocast frame 300 can converge on the network 
management entity as the intermediate switches learn the address 
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in the network. The present invention is not limited to L2 
switch networks, however, and can be implemented in more complex 
switch systems, for example, those using routing. 

Thus, it may be desirable to insert specific character 
strings into the MIB Autocast frame when packets are forwarded 
across a routed (L3) environment. In an embodiment of the 
current invention, MIB Autocast frame may be configured to accept 
arbitrary length field 318, 320 located, for example, following 
Type field 306, and preceding OPCODE field 308. This may be 
performed by requesting an internal frame storage buffer from the 
switch device. One difference between this mechanism and the 
manner in which a data frame would use an internal frame storage 
buffer, is that the data frame tends to return the buffer once 
it had been re-transmitted to the appropriate port (s) . For a 
frame buffer to the MIB Autocast process, the buffer is reserved, 
and is not returned to the internal free pool. When MIB Autocast 
frame 300 is constructed, and if the header insertion feature is 
enabled, the address of the buffer location that was returned by 
the switch device, and held in an internal switch device 
register, is read and a specific number of header bytes, which 
also are register programmable, can be inserted into the MIB 
Autocast frame . 

Note that it desirable that the host device writes the 
correct number of bytes of header information into the specified 
buffer location, and program the length of the header field. The 
device also should compute and provide any error check fields 
that are associated with the header information. It is desired 
that the switch device assemble the entire frame, including the 
inserted header, and compute and append the normal information 
prior to queuing for transmission . In one embodiment of the 
present invention, organizationally unique identifier (OUI) 320 
in packet 300 identifies it as a management (push) , or MIB 
Autocast, frame. 
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Also, MIB Autocast frame 300 could be identified using a 
special "push" Type field 318. Furthermore, the MIB Autocast DA 

5 field 302 can be an individual address, a multicast address, 
including reserve multicast, or a broadcast address. In an 
embodiment of the present invention, reporting can be turned on 
or off, and resolution can be set high or low, using simple 
commands that are intercepted and interpreted by the switch 

10 internally, or by an external microcontroller. MIB Autocast 
frame 300 can be enabled or reactivated after an error or 
threshold condition is detected, and are sufficiently small and 
infrequent so as not to adversely increase the traffic load on 
the network. It may be desirable to have a smart agent capture 

15 MIB Autocast frame 300, and process and store it, and/or display 
it at a later time. Furthermore, the smart agent may issue 
configuration messages to modify the content or the frequency of 
MIB Autocast frames. Also, it may be desirable to have MIB 
Autocast-enabled hubs and switches to decrement a MIB Autocast 

20 frame field, such that it is known how many switch hops the MIB 
Autocast frame has traversed before reaching the current 
destination . 

FIG. 4 illustrates a multiport hub 400, exemplary of another 
embodiment of the invention herein. Registers containing one or 

25 more information representative of one or more states of the 
network, including, for example, status and operational 
information, may be found in integrated network switch device 
402, or in SSRAM 404a, 404b. In some instances, the information 
to be pushed may be stored in the memory of EEPROM 406, RAM 408, 

30 or FLASH memory 410. In any event, it is most desirable that 
switch device 402 act as a server to push the one or more 
information to the clients coupled thereto, as illustrated in 
FIG. 1. 

While a variety of registers in exemplary hub 400 allow 
35 flexibility in configuring the MIB Autocast features, one of its 
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key applications is providing very low cost and minimal overhead 
network management. For this reason, it is highly desirable to 

5 have the exemplary switch device operate without a general 
purpose microprocessor , and have a simple enable/disable of the 
MIB Autocast feature with simple default parameters. 

One way to achieve this goal is to provide, on the switch 
device, an optional external pin strap 414 to allow MIB Autocast 

10 to either be enabled or disabled at power on. When this option 
is used, and assuming that no external processor is employed to 
change the default register configurations, the MIB Autocast 
frames can be generated at a default interval, and the state of 
all ports can be queued and transmitted on all active ports of 

15 the exemplary switch device, except for the SMP. 

While it is desirable to have a processor-less solution, one 
implementation of the present invention can use a simple external 
microcontroller 416. For instance, microcontroller 416 can be 
used to implement sophisticated password or authentication 

20 techniques to activate vendor-specific system or device 
configuration features. Microcontroller 416 may be used to 
program a unique 48-bit MAC address, for example, in the IEEE 
802.3 format, into a MIB Autocast Source Address Register, such 
that a frame transmitted by the device always will be identified 

25 as having originated from a unique switch. It is also possible 
for the present invention to be implemented in switch device 402 
which integrates microcontroller 416 therein. Device 402 may 
also integrate serial EEPROM read circuit 406. Either the 
microcontroller 416, or EEPROM read circuit 406, can take the 

30 desired default MIB-Autocast parameters from external non- 
volatile memory 410, and write them to the appropriate internal 
registers 420. 

SSRAM buffer 404a, 404b, also can be used to incorporate a 
routing field into the frame or to save additional diagnostic, 
35 character string and/or configuration information. This 
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information may be static or variable depending on the 
performance or the operational state of switch 402. 
Microcontroller 416 can update these fields routinely, which then 
also can be cast in the proposed manner. It also may be 
desirable to suppress casting MIB Autocast frames to a port that 
is disabled, that suffered a link fail, or that otherwise has 
been isolated. Furthermore, MIB Autocast-enabled device 400,402 
can use a specific frame to turn on a feature or to modify the 
configuration of the MIB Autocast frame (e.g. frame 300 in FIG. 
3) , using hardware or software security or encryption techniques. 

FIG. 5 illustrates a multiple switch hub 500, with each 
switch 502, 504 being similar to device 200 found in FIG. 2, and 
the associated data and configuration message flow for hub 500 
being similar to device 200. Expansion ports 506, 508 on 
respective devices 502, 504 allow interconnection with other 
devices. A frame received on a port of one switch device with 
a DA unknown within the local address table, or a DA known to 
belong to a port on another switch device, will be forwarded 
across appropriate expansion port 506, 508. The look-up and 
learning mechanism by which MAC addresses are resolved in the 
address table is well-known to those skilled in the art. 
Configuration and status read/write operations to access internal 
switch device registers may be performed by CPU 510 using serial 
management port 512. 

For MIB Autocast frames, which can be generated internally 
to switch devices 502, 504, additional registers, for example, 
in SSRAMs 514a, 514b, 516a, 516b, can be configured to allow the 
frames generated by one device, e.g., device 502, to be cast to 
any subset of the ports on another device, e.g., device 504, and 
to ensure that these frames do not circulate or replicate. Each 
device 502, 504 can insert its own chip ID in the port ID field 
of the MIB Autocast frame, similar to Port field 310 in FIG. 3, 
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so the frame is uniquely distinct and can be attributed to an 
individual switch device. 

5 Switch 502 (chip ID=0) generates an MIB Autocast frame for 

a port, and casts the frame to the ports enabled in its MIB 
Autocast ports mask register 522. In this case, the register is 
set to include the expansion port, as well as those network ports 
that are required to forward the frame. In this example, the 

10 frame is passed along the expansion port to switch 504 (chip 
ID=1) . In switch 504, a special set of registers 524 can be 
configured which include the multiport address and multiport 
registers. These registers can be extensions of the address 
resolution table (ARL) and can be used in the address resolution 

15 process. Normal address entries in the switch device ARL always 
resolve to a single port egress decision. 

The two pairs of multiport address/vector registers allow 
any 48-bit unicast or multicast address to resolve to a port 
vector, which means that frames can be queued to any programmable 

20 set of egress ports. In this example, the multiport address 
register can be programmed with the MIB Autocast destination 
address, i.e., the address of the stations in which the MIB 
Autocast management entity will reside. The multiport vector 
register would be programmed with the ports that are to cast the 

25 MIB Autocast packet which may include the expansion port. 
However, because the switch device typically masks the ingress 
port from the egress port vector before initiating the forwarding 
process, MIB Autocast frames received from the expansion port 
will not be forwarded back to it. It is desirable that the chip 

30 ID be preserved within the frame. 

The switch device with switch 504 (chip ID=1) also would 
have its MIB Autocast port mask register programmed to forward 
its frames across the expansion port to switch 502 (chip ID=0) . 
Switch 502 would have the similar multiport address/vector 

35 register set up such that it would forward MIB Autocast frames 
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generated by switch 504 (chip ID=1) to the correct set of egress 
ports. These egress ports are not necessarily the same set of 
ports to which switch 502 (chip ID=0) MIB Autocast frames are 
forwarded. 

Another embodiment of the present invention is a 
communication apparatus 600 as seen in FIG. 6. Apparatus 600 
includes a network information receiver 602 which communicates 
with a communication network 604 and a network information table 
606 used to store network information from the network 
information receiver 602. Apparatus 600 also includes a network 
information transmitter 608, which may be used to selectively 
transmit stored network information across communication network 
604 to clients 610a-610c. The selective transmission is a "push" 
transmission and can be a unicast, a multicast, a broadcast, or 
a hybrid thereof. 

FIG. 7 illustrates apparatus 700 embodying the present 
invention in which transceiver (PHY) 702a, 702b and switching 
fabric 704 are integrally combined with network information 
detector 706. Apparatus 700 may be in the form of a network hub 
which can act as an MIB server which pushes information to 
clients 712a, 712b, 712c, in communication network 716. Hub 700 
further may integrate network information transmitter 708, and 
network information table 710, or both. Although optional, it 
may be desirable to include network operation analyzer 714 to 
selectively analyze the information stored in network information 
table 710 and thereby produce an operational information, for 
example, of the operational state of the network. 

In the latter instance, the network operations analyzer can 
analyze the network information and produce operational 
information of the operational state of that network. As used 
herein, the network hub may be a switch, a repeater, a bridge, 
a router, or a hybrid thereof. It is further desired that the 
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network hub has multiple ports for example, four, eight, or more 
ports . 

5 Although apparatus 700 can be used in an OSI Layer 2 network 

application, it also may be used in an OSI Layer 3 network 
application or a hybrid device spanning these two layers. It is 
desirable that the network information transmitter 708 
selectively push MIB information, or other information which can 

10 be representative of operational information of the operational 
state of the network, to clients 712a, 712b, and 712c. It is 
desirable that the information be selectively pushed to clients 
712a, 712b, 712c through unmasked ports of hub 700, and blocked 
from others of clients 712a, 712b, 712c by selectively masking 

15 ports of hub 700. The server can selectively push the 
operational information to one or more network clients using 
unicast, broadcast, or multicast techniques, or a hybrid thereof. 
It is desired that the network hub 700 be devoid of a 
microprocessor or microcontroller, although alternative 

20 embodiments of the push-transmission hub can employ a 
microprocessor, a microcontroller, or a EEPROM read-state 
machine . 

Many alterations and modifications may be made by those 
having ordinary skill in the art without departing from the 

25 spirit and scope of the invention. Therefore, it must be 
understood that the illustrated embodiments have been set forth 
only for the purposes of example, and that it should not be taken 
as limiting the invention as defined by the following claims. The 
following claims are, therefore, to be read to include not only 

30 the combination of elements which are literally set forth but all 
equivalent elements for performing substantially the same 
function in substantially the same way to obtain substantially 
the same result. The claims are thus to be understood to include 
what is specifically illustrated and described above, what is 

35 
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conceptually equivalent, and also what incorporates the essential 
idea of the invention. 
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CLAIMS 



5 1. A network hub in a communication network comprising a 

server, the server pushing status information to a client. 

2. The network hub of claim 1, wherein the server unicasts 
the information. 

10 

3. The network hub of claim 1, wherein the server 
transmits the information to a plurality of clients. 



4. The network hub of claim 1, wherein the server 
15 broadcasts the information. 



5. The network hub of claim 1, wherein the server 
multicasts the information. 



20 6. The network hub of claim 1, wherein the hub comprises 

one of a switch, a repeater, a bridge, a router, a gateway, and 
a hybrid thereof. 



7. The network hub of claim 6, wherein the network hub 
25 comprises one of an OSI Layer 2 network switch, an OSI Layer 3 

network switch, and a hybrid thereof. 

8. The network hub of claim 1, wherein the hub is devoid 
of a microprocessor. 

30 

9. The network hub of claim 1, wherein the information 
comprises a predefined status field. 

10. The network hub of 9, wherein the predefined status 
35 field comprises a push transmission field. 
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11. The network hub of claim 6, further comprising a 
plurality of ports. 

5 

12. The network hub of claim 11, wherein the operational 
information comprises a predefined status field. 

13. The network hub of claim 12, wherein the predefined 
10 status field corresponds to at least one of the plurality of 

ports . 

14. The network hub of claim 1, further comprising memory 
register for storing the information therein. 

15 

15. The network hub of claim 1, wherein the information is 
a management information base (MIB) statistic. 

16. The network hub of claim 1 further comprising a MIB 
20 engine. 

17. The network hub of claim 16 further comprising a 
switching fabric and a transceiver (PHY) integrally contained 
therein . 

25 

18. The network hub of claim 17 further comprises an 
address resolution table integrally contained therein. 

19. The network hub of claim 15 further comprising a MIB 
30 engine. 

20. The network hub of claim 9 further comprising a MIB 
engine for pushing the predefined status field. 
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21. A communication apparatus, comprising: 

a. a network information table storing network information 
5 from the network information receiver; and 

b. a network information transmitter selectively push 
transmitting the network information in the network information 
table . 



10 22. The communication apparatus of 21, further comprising 

at least one of: 

a. a network information receiver, operably coupled 

with a communication network and the network information table, 

receiving network information; and 
15 b. a network operations analyzer analyzing the 

networking information in the network information table and 

producing information of a state of the network. 



23. The communication apparatus of 22, comprising a hub, 
20 a switch, a repeater, a bridge, a router, a gateway, and a hybrid 
thereof . 



24. The communication apparatus of claim 21, comprising a 
plurality of ports coupled to the network information 
25 transmitter. 



25. The communication apparatus of claim 23, comprising one 
of an OSI Layer 2 network switch, an OSI Layer 3 network switch, 
and a hybrid thereof. 

30 

26. The communication apparatus of 
of an OSI Layer 2 network switch, an OSI 
and a hybrid thereof. 



claim 24, comprising one 
Layer 3 network switch, 
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27. The communication apparatus of claim 26, wherein the 
plurality of ports comprises four ports. 

28. The communication apparatus of claim 26, wherein the 
plurality of ports comprises eight ports. 



29. The communications apparatus of claim 21, further 
10 comprising a PHY and a switching interface, each of the network 
information receiver, the network information table, and the at 
least one of the network information transmitter and the network 
information detector being integrated into the network hub. 

15 30. The communication apparatus of 29, wherein the network 

hub comprises one of a switch, a repeater, a bridge, a router, 
a gateway, and a hybrid thereof. 



31. A communication apparatus, comprising: 
20 a. a network information receiver, operably coupled with 

a communication network, for receiving network information; 

b. a network information table for storing network 
information from the network information receiver; 

c. a network operations detector detecting the networking 
25 information and producing operational information of an 

operational state of the network; and 

d. a network information transmitter, for transmitting the 
operational information of an operational state of the network. 



30 32. The communication apparatus of 31, further comprising 

a network hub. 



33. The communication apparatus of 32, wherein the hub 
comprises one of a switch, a repeater, a bridge, a router, a 
35 gateway, and a hybrid thereof. 
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34. The communication apparatus of claim 33, comprising a 
plurality of ports. 

35. The communication apparatus of claim 33, comprising one 
of an OSI Layer 2 network switch, an OSI Layer 3 network switch, 
and a hybrid thereof. 

36. The communication apparatus of claim 34 , comprising one 
of an OSI Layer 2 network switch, an OSI Layer 3 network switch, 
and a hybrid thereof. 

37. The communication apparatus of claim 36, wherein the 
plurality of ports comprises four ports. 

38. The communication apparatus of claim 36, wherein the 
plurality of ports comprises eight ports. 

39. The communications apparatus of claim 32, further 
comprising a transceiver (PHY) and a switching fabric, each of 
the network information receiver, the network information table, 
and the at least one of the network information transmitter and 
the network information detector being integrated into the 
network hub. 

40. The communication apparatus of 39, wherein the network 
hub comprises one of a switch, a repeater, a bridge, a router, 
a gateway, and a hybrid thereof. 
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METHOD AND APPARATUS FOR A NETWORK HUB TO DIAGNOSE 
NETWORK OPERATION AND BROADCAST INFORMATION 
5 TO A REMOTE HOST OR MONITORING DEVICE 

ABSTRACT OF THE DISCLOSURE 

A network hub in a communication network that acts as a 
server to network clients to push, or transmit, information 

10 regarding the state of local and remote devices and networks. 
The information can be one, or more, status information, which 
information can be one or more predefined fields in a frame, 
which represents a packet of data. In one embodiment, it is 
desirable that the frame be a "legitimate" Ethernet-type frame. 

15 The status field can be a "push"-Type status field. The push 
operation can be a unicast, a multicast, or a broadcast, or a 
hybrid transmission. The hub can be a switch, repeater, a 
bridge, a router, a gateway, or a hybrid thereof. Also, the hub 
according to the present invention can be an OSI Layer 2 device, 

20 an OSI Layer 3 device, or a hybrid thereof. It is desirable that 
the hub be devoid of a microprocessor. As described herein, the 
hub may have plural ports, for example, four, eight, or more 
ports . 

25 
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